Vulnerabilities have been found in various types of software such as, for example, operating systems and software applications. The term “vulnerability” refers to a security defect in a system or software so that an attacker can potentially violate the confidentiality, integrity, operations, availability, access control, and/or data of the system or software. Vulnerabilities may result from bugs or design flaws in the system or software.
Security bulletins are issued by software vendors and security fixes (e.g., software patches which are updates to software) are typically applied to software, as a response to a discovered vulnerability in software. For example, Microsoft Corporation provides software updates or security patches in, for example, WINDOWS® update. However, applying a security fix to a system (e.g., server) may require downtime and re-booting of the system and may disrupt or make unavailable the services provided by the system. This disruption or system unavailability can lead to added cost for the user of the system.
System administrators often bundle the security fixes together that they download/receive, and may apply these bundled fixes on a pre-scheduled cycle in order to reduce the time that they spend in applying the fixes. However, some security fixes may be required to apply to the system before the pre-scheduled cycle, particularly if the discovered software vulnerability has a high severity (e.g., there is a high likelihood that exploits will occur on the vulnerability and/or the damage that an exploit can cause is high).
Security bulletins are placed by software vendors in customer-accessible databases and provide additional details that describe, for example, a discovered software vulnerability, the severity and urgency of the problem (e.g., if the vulnerability requires a critical update), likelihood of an exploit and the spread of the exploit, the potential damage that a vulnerability exploit can cause to the system or software, instructions on the security fixes (e.g., patches), and/or the like. However, the posting of security bulletins also potentially provides information to potential hackers on how to exploit the discovered vulnerability. Additionally, an administrator (or user) may not necessarily apply a security fix to a system, immediately or at all, because the administrator may need to first test the security fix for potential harm to the system and/or applying the security fix will cause downtime or disruption to the system.
In a highly-used or highly-available system (e.g., servers that are used or accessed by many computers), the cost of having the system as unavailable can be high. As a result, an administrator may wait for a certain period of time before applying the security fix to the system in order to delay the downtime or to schedule the downtime when few users are accessing the system. Furthermore, in other network systems, a network administrator would push the security fix downstream to individual users of computers, and these individual users may not necessarily apply the fixes or may delay in applying the fixes to their individual computers. Additionally, some administrators or users might delay in applying the security fix if the system is protected by a firewall.
As a result, the above constraints (and other possible constraints) may prevent administrators (and/or users) in applying the security fixes, immediately or at all. The administrators are making their decisions on when to apply the fixes based on the relative risks of quickly applying the fixes versus the relative risks of delaying in applying the fixes. In other words, the administrators are weighing the cost of immediately applying the fixes (which leads to costs/expenses associated with, e.g., system downtime) versus the cost of potential damage to the system if the vulnerability is exploited by a hacker. The decision of administrators to delay in applying the security fix takes into account the expected severity of vulnerability exploit damage and the probability of an exploit occurrence.
There is a need to solve the problem of protecting a system from vulnerability exploits, between the time when a vendor posts a security bulletin for a discovered vulnerability and the time when a security fix for the discovered vulnerability is actually applied to the system.